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ABSTRACT 


' 1 ) 


This volume, Functional Requirements , details the functional 
perfomance, and general requirements for the FBI Fingerprint 
Identification system* It will be used in evaluating the AIDS III 
system concept and the alternative systems that will be studied in the 
second phase of this work. The document describes the current system 
and subsystem used by the Identification Division* It also discusses 
system constraints that dictate the system environment and describes 
boundaries within which solutions must be found. The Functional 
Requirements section discusses the functional requirements and relates 
them to the performance' requirements. These performance requirements, 
listed in the’ Measure pf Effectiveness Volume VIII, are then related 
to their applicable qiibsystems. The Interface Requirements section 
describes the flow of data, documents, or other pieces of information 
from one subsystem to another or from the external world into th€ 
identification system. Finally, the General Requirements section 
lists the requirements and design standards for a computer-based 
system. For a synopsis of this entire report see the Executive 
Summary in the Compendium (Volume I). 
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SECTION I 


i^;troduction 

A. DEFINITIONS AND PURPOSE 

There are four tenia used extensively in this docuawnt yhich awy 
not be familiar to the reader. These are: 

(1) Functional requireaMents . 

(2) Performance requirements. 

o 

(3) Top down functional analysis. I< 

(4) Measures of effectiveness. 

Functional requireiaents are the collection of the capabilities 
that a aystem and its subsystem must possess to fulfill the objectives 
of the users of the system. In other words, they are what the system 
needs to do to meet its intended purpose or reason for existence. The 
user requirements that are fulfilled are under the control of the 
operator and/or owner of the system. Functional requirements are not 
design characteristics. Rather, functional requirements indicate to 
the designer the capabilities that must be incorporated into the 
design. 

Perfoinnance requirements describe the level of quality with 
which eac|i function must be accomplished. Consequently, performance 
requirements are generally quantifiable and, as such, can be measured. 

j The determination of the functional requirements of a system can 
be accomplished in more than one way. An extremely effective method 
is top down functional analysis (TDFA). (See Volume VII for a TDFA of 
the FBI's Identification Division.) This method starts at the highest 
level objective and by asking the question, "what functions need to be 
performed to achieve this objective," a division into subfunctions is 
made. When the complete set. of sub functions supporting the function 
has been identified, each of the subfunctions is in turn subdivided 
until the lowest useful level is reabhed. Deciding when the lowest 
useful level has been reached is not easy. One test is that further 
subdivision requires design decisions. At this point, the process 
should stop. 

Measures of effectiveness (MOE) are the parameters used to gauge 
the state and performance of a system in attempting to achieve its 
goals. 

Measures of effectiveness were used as a source of performance 
requirements since performance requirements are a subset or an 
essential ingredient of the measures of effectiveness. The measures 
of effectiveness (See Volume VIII) are primarily intended for use in 
the second phAse of the study and therefore are different in approach 
and in scope. 


The purpose of this docusient is to collect end list the 
functionelr performance^ and general requiresMnts for the FBI 
fingerprint identification system. The document will be used to 
evaluate the AIDS III system concept and the alternative systems to be 
studied in the second phase of the study (Reference 2). 

This document can also be used as a system development topi for 
contracting for system design and implementation and as a basis for 
acceptance testing both at the system and subsystem levels. 


B. SCOPE 

/ All the functional, performance, interface, and other general 
requirements for the FBI Identification process are collected ^n this 
document. The document will be used primarily for the evaluation of 
Rockwell International's AIDS III design concept. This Phas',^ I 
(Reference 2) evaluation will exclude the Mail Room at either end of 
the processing as well as the latent print identification. When Phase 
I is complete, alternative design concepts will be evaluated in a 
second phase. At that time, the scope of this document may be changed 
to include data collection in and beyond the Mail Room and the 
identification of latent prints. 


C. METHODOLOGY 

The development of functional requirements is illustratedi in 
Figure 1-1. First a TDFA is performed. This analysis breaks the 
objectives and functions of the Identification Division into 
increasingly more detailed subfunctions until further breakdowns 
become so design dependent as to no longest be functional in nature. 
Functions that are candidates for automation are identified. Those 
functions that W!?re automated by AIDS I and II are marked as well as 
those which are to be automated by AIDS III (Reference 1). 

A functional design is then created that requires the 
identification of subsystems. Some design decisions are involved in 
this step but are minimised. Next, functional interfaces between 
subsystems are determined as well as function and major components 
such as data files. 

In parallel with these steps, MOE are developed. The MOE are 
then related to the functional system design by correlating the MOE to 
the functions of the TDFA by subsystem. 

The next step requires the involvement^ of the FBI since the 
designer cannot know the importance of accuracy of search, speed of 
response, etc., without consulting with the operators and sponsors of 
the system. After determining system level"|i>erfonBance requirements, 
the system engineers can allocate these to the affected subsystem, 
which leads to a complete set of system and subsystem functional 
requirements. These requirements can be used to communicate to the 
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Figure 1^1* Functional Requirements Development 




builders of the system with the assurance that the system will perform 
the necessary functions , that all interfaces will be properly 
designed, and that the system will respond and perform as intended. 
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SECTION II 


SYSTEM AND SUBSYSTEM DESCRIPTIONS 


A. FINGERPRINT CA^ AND EXTERNAL DOCUMENT FLOW 

Figure 2-1 shows the flow of fingerprint cards and other 
external documents that are received by the FBI and processed through 
the Identification System. As discussed earlier, the scope of this 
document in Phase I is bounded by the Mail Room as the point of data 
collection and response disbursement. 

The Data Collection Subsystem (see Figure 2-1) receives the 
requests from the Mail Room. Alien and identification cards are 
immediately sent to the civil file for storage. (Those documents that 
must be searched in Card Index are sent to the manual system.) In the 
Data Entry Subsystem incomplete requests are returned to the 
originating users and the data on the request doctsnents are entered 
and verified. 

The subject search is done first. A response is returned to the 
terminal operator. This Response will indicate to the operator where 
the documents are to be routed. Military requests with no candidates 
from the subject search are not fingerprint (technical) searched and 
are sent to the civil file for storage. Documents that are to be 
returned to the user with no further processing are sent to the 
Response Generation Subsystem. The manual system can also be a source 
for the Data Entry Subsystem when a positive identification is made as 
a result of a search in the manual system. If the subject’s file 
indicates that the records are in the automated subject file, that 
file must be updated with the new information. 

Criminal and civil search requests with no ’tentative search 
candidates are sent to the Technical Search Subsystem. Search 
requests with search candidates go to the Identification/Verification 
(l/V) Subsystem for a positive identification. If a positive 
identification is not made in the l/V Subsystem, then these candidates 
are routed to the Technical Search Subsystem for further search. 

In the fingerprint search all searches that produce no 
candidates are sent to the Response Generation Subsystem and those 
with candidates are sent th the I/V Subsystem. If no identification 
can be made, the document is sent to Response Generation for the 
appropriate response. If it is a criminal inquiry it also receives 
file updating, ^en a positive identification is made, the document 
will be sent to Response Generation for the response and file updates, 
or, if the FBI number indicates that the subject's file is in the 
manual system (Card Index), the request doctanent will be routed to the 
manual system. If necessary, the Response Generation Subsystem will 
generate an index card that is also sent to the manual system to be 
filed in the Card Index files. 
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From the Response Generation Subsysten; retained documents are 
forwarded to either the Civil or the Archival Criminal File. 
Documents to be returned and responnes are sent to the contributors. 


B. SYSTEM DATA FCOW 

Figure 2-2 shows the logical data interfaces between the 
functional subsystems in the Identification System. 

Data is received from the users and contributors in the external 
world by the Data Collection Subsystem. In the Data Entry Subsystem 
this data is converted into machine-readable characters in appropriate 
formats for that kind of data; i.e. search requests, dispositions, etc. 

The System Supervisor serves as a control interface between the 
subsystems to monitor and control the transactions as they pass 
through the system. The data are made available directly to the 
appropriate subsystem for processing. 

Pointers to the data are passed through ttie System Supervisor, 
For example, in the case of a search request, a control record is 
generated indicating that the Subject Search Subsystem is processing a 
specific process control number (PCN). The record contains other 
information such as date and time of release to the subsystem ani the 
type and source of the transaction for audit trail and statistical 
reporting. When processing is completed in the Subject Search, the 
response (either a candidate or no candidate indication) is passed 
back to the Data Entry terminal operator through the System 
Supervisor. The list of candidates, if any, is made directly 
available to the Operator , 

The automated responses are generated by accessing the Subject 
Data File and are distributed to the users. Figure 2-2 also indicates 
the responsibilities and relationships of subsystems and each of the 
major master files in the system. 

'O 
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Figure 2-2. System Data Plow 














SECTION III 


SYSTEM CONSTRAINTS 


The objectives^ that are externally imposed and thus dictate i? 
the system environment are system constraints. They define the 
boundaries of a solution space within which a technically > 
operationallyf and economically feasible solution must be found in 
order to establish system feasibility. 

The objectives, which are constraints as opposed to requirements 
(which are listed in Section IV), can be paraphrased as follows: 

V 

(1) Automation should not require personnel to work hours 

different from those already established for the manual 
system. The maximum daily work loads should be processed 
in the two 7.5-hour shifts that are staffed at a ratio of 
2 to 1, day shift to night shift. 


(2) Implementation of automation must occur within the work 
space alloted to the Identification Division. No 
consideration can be given to adding floors to the 

J. Edgar Hoover Building nor to moving to a new building 
to accommodate automation. 

(3) Processing the work by automated procedures should not 
require a change in the size of the fingerprint card form 
nor a change in th'd information contained on it. Manual 
forms now in use must be processed in the automated system 

O 

(4) Daily work loads must be satisfied using the five existing 
automatic Fingerprint Reader Systems (APRS). - 


I 


^Stated in the Appendix of "Automation of FBI Identification 
Functions: Feasibility Study Work Requirements Statement," 

unnumbered document. Federal Bureau of Investigation, Technical 
Services Division, May 22, 1979. 
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SECTION IV 

FUNCTIONAL REQUIREMENTS 


This section lists the system and subsystem functional 
requirements. Functional requirements are purely qualitative in 
nature as opposed to performance requirements (see Section V), which 
may be qualitative or qpantitative. 

The functions for the system and for each subsystem are shown in 
Figures 4-1 through 4-9> which also show functional interfaces. 


A. SYSTEM 

Figure 4-1 shows the functions from the TDFA of the 
Identification System. Listed on the chart a^e the subsystems that 
comprise the system and the major external interfaces, other systems, 
and files within the FBI that lie outside thie scope of this dociraent. 


B. SUBSYSTEMS 

Figures 4-2 through 4-9 show the TDFA functions performed by 
each of the subsystems listed in Figure 4-1. These charts list major 
data files included in the subsystem and the major interfaces to other 
subsystems. Different interfaces are listed on each side of the chart 
with the appropriate heading. In most cases, the interfaces are 
either functional (data) or physical (fingerprint cards). Where the 
Subsystem deals with the external world, the external and internal 
interfaces are on opposite sides of the chart. If there are only 
functional interfaces, these were divided in a manner that would 
facilitate the reader's understanding Of the data flow. These 
headings are important to the Interpretation of the charts. 

The functions listed within each chart are only the highest 
applicable level listed in the TDFA. The reader is referred to the 
TDFA (Reference 1) for the breakdown of these functions into their 
components. 
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IDENTIFICATION/VERIFICATION SUBSYSTEM 



Figure 4'^6. Identificatiqin/Verification Subsystem 


FUNCTIONAL INTERFACES 



functional intsfaces 



Figure A— 8, System Supervisor 



Figure 4-9. Technical Support Subsystem 


SECTION V 


PERFORMANCE RBQt^XREMENTS 

This section lists and describes Lh« system performance 
requirements and, where possible, relates them to the subsystems. Of 
the 10 performance requirements, five are quantifiable and can be 
allocated among subsystems and five are not quantifiable. 

Quantifiable performance requirements are: 

(1) Average response time. 

(2) Maximum response time. 

(3) Storage capacity. 

(4) Availability (including reliability). 

(5) Accuracy, 

Qualitative performance requirements are: 

(1) Observability. 

(2) Operability. 

(3) Maintainability. 

(4) Integrity, 

(5) Security. 


The first three performance requirements (see Figure 5-1) — 
average and maximum response time and capacity, especially storage 
capacity — are interrelated because they deal with the problem of how 
much data must be held by the system and by each subsystem at any one 
time. How rapidly the data must moVe both in terms of the average 
processing time and the longest allowable time for any transaction are 
grouped together because of this storage /’^terrelationship. 

(1) Average response time — The average time at which work 

has to be processed through the systesi. If queues of work 
that cannot be processed by the next station are defined 
to exist in the subsystem that has just produced them or 
the one that is about to accept them, then the System 
Supervisor 01:^1 y passes control and file pointer 
information that is not in the pipeline of the process. 
Response time can be affected if queues build for the 
System Supervisor to perform the message switching. 
Consequently, the System Supervisor will receive 
allocation of average response time. 
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(2) Maxinturo response tine — The maximum allowable time that 
any one piece oJ[ work can dwell in the system prior to 
completion of processing. This maximum allowable time is 
normally associated with some probability since there is 
always the possibility of an unforeseen set of conditions 
or transactions that will, however rarely, exceed the 
specified resf/bnse time. 

!i 

Note 1. The FBI Aifes 111 Design Guidelines^ rei^uire that the 
response time will be 8 work'-hours (for routine) or ,30 minutes 
(for expedite) for 95% of the fingerprint cards; 4 v- hours 
(routine) Or 8 hours (expedite) for 99% of the cards, and 96 
hours (routine) for 99.9% of the fingerprint cards. This 
performance requirement may be too stringent, but it has been 
agreed between JPi and the Identification Division that this and 
the other requirements will stand until it is shown that no 
operationally feasible solution exists within the solution 
space. At that time, the Identification Division will relax 
these boundaries. This solves the problem for phase 1 of the 
JPL study. A more substantial solution will be sought for the 
evaluation of the alternative systems in the second phase. 

(3) Permanent storage capacity — Applies to file size and 
therefore is allocated to those subsystems that manage 
data files; i.e., Subject Search, Technical Search, and 
the Identification/Verification Subsystems. The estimated 
file sizes for AIDS III were defined in the AIDS III 
Deeign Guidelines. 

(4) Temporary storage capacity — Refers to the amount of data 
that must be handled concurrently or the work load that 
the subsystems must process in a period of time. The 
specific requirements for each subsystem are derived from 
the projected design work load requiret.ents defined by the 
FBI.^ 

Note 2. The System Supervisor is allocated permanent and 
temporary storage capacity ^6 that the data are available for 
work load monitoring and controlling and statistical reporting 
required of current or historical data in an interactive or 
batch mode. 

The jtyio remaining quantifiable requirements are: 

(5) Availability including reliability -- Ratio of up to total 
time of required system operation. Total time is equal to 
up time plus down time. Down time consists of the time to 


^"AIDS’ill Design Guidelines," attachment to letter from 
N. F. Starnes, Assistant Director, Identification pivision, 
Federal Bureau of Investigation, to R. E. Hilderhrand, Rockwell 
Internatrcral , October 26, 1979. 
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detect a failure, the tine to,, isolate, repair (including 
maintenance personnel travel), and to restore service. 

Note 3. The availability requirements for the subsystem 
hardware is based upon the data in an AIDS 111 Technical Memo 
from Rockwell.^ ■' 

(6) Accuracy — Refers to the accuracy of searching, 
identifying, and updating files. This performance 
requirement applies to only four subsystems: Data Entry, 

Subject Search, Technical Search, and Identification/ 
Verification. Accuracy can be subdivided into three major 
categories: accuracy of the data entered for file update; 

searching and matching on the basis of descriptive 
information or fingerprints, which includes keying in the 
search data and such other functions as classification of 
fingerprints; and the final identification process, which 
produces only one identification or no identification. 

(See Figure 5-2.) 

Note 4. It has been established that the allowable miss k4te 
for false or wrong identifications is zero (accuracy probability 
required for identification is 1.0). In order to maintain a 
file from (Which no false idehtification can be made, the 
accuracy of the file update procedure must not allow any 
erroneous data to enter the file. This applies only to the 
conversion of data from the source document to the file; it does 
not apply to processes taking place outside the scope of this 
document. There is, however, an allowable miss rate for missed 
identifications. This can occur in the Data Entry, Subject 
Search, Technical Search, or Identification/Verification 
Subsystems. For the purpose of Phase 1 of the JPL study, the 
requirement will be that the new system must perform better than 
the existing^ manual system in making identifications. This 
performance level is documented in AIDS III Evaluation Report , 
Volume V: Current System Evaluation (Reference 3). This level 

of accuracy may need quantifying on an absolute scale for the 
evaluation of alternatives. 

The remaining requirements are not quantifiable and therefore 
cannot be allocated to subsystems (see Figure 5-3): 

(1) Observability — The ability to monitor the performance of 
the system and detect surges or imbalances in work load as 
well as failures. 

(2) Operability — The ability to operate the system and the 
ease with tdiich it can be operated both in normal and 
unusual circumstances. 


^"AIDS III Technical Memo: Major Component MTBF/MTTR Sumnary and 

Availability Design GoaIg" by R. E. Davis, Rockwell 
International, November 12, 1979. 
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(4) Integrity *— Applies chiefly to data and includes the 
provisions for not corrupting or losing data. 

(5) //Security Involves the physical security of the system 

and its ability to prevent unauthorized access to or 
alteration of the information stored or in the process of 
flowing through the system. 
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SECTION VI 


INTERFACE REQUIREMENTS 

The performance requirements listed in the measures of 
effectiveness that apply to interface requirements are the capacity 
for data, documents, or other pieces of information that pass from one 
subsystem to another or from the external world into t;he system. The 
performance requirements that also apply areii operability, security, 
reliability (which can,; be included as part o^f availability), 
observability, and maintainability (see Figu'ire 6-1). 

Interfaces between subsystems and between the system and the 
external world are defined as those places in the systems where the 
two subsystems meet. They have a physical reality; however, it is 
assumed that no processing goes on within the interface and that no 
storage is available. Any buffering or storage required is performed 
by the interfacing subsystems themselves rather than the interface. 
Consequently, storage capacity requirements do not apply to interface 
requirements. Temporary capacity and average response time can be 
lumped together because there is no queue. The temporary 
capacity/ response time requirements in Figure 6-1 have been derived 
from the design work load^ required by the FBI for AIDS III. 

Similarly, since there is no processing performed in the 
interface, accuracy does not apply. 

Maximum response time also is not applicable to interfaces since 
without processing or storage there is no delay assumed in the 
interface. 

To determine this applicabilit'y of performance, interfaces were 
typed as follows: fingerprint card and document interfaces, computer 

data interfaces, external interfaces, internal interfaces, and the 
special interfaces provided to the System Supervisor and Technical 
Support Subsystem. After examination it was discovered that the 
Technical Support Subsystem interfaces are not areas of system design 
and consequently though important are not applicable to this 
document. System Supervisor subsystem interfaces are all computer 
data interfaces and consequently can be put into that category. 
Similarly, inspection of the interface charts (Figures 4-1 through 
4-9) shows that internal interfaces are all fingerprint card and 
document interfaces and consequently can be placed in those categories . 

External interfaces will change if the present system, which 
employs mail both to and from the external world, is replaced by one 
that distributes processing or communications to the field employing 


^"AIDS III Design Guidelines," attachment to letter from N.F. Starnes, 
Assistant .Director, Identification Division, Federal Bureau of Invest! 
gation, to R.E.Hilder brand, Rockwell International, October 26, 1979 
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SYSTEM SUPERVISOR - SUBJECT SEARCH 
SYSTEM SUPERVISOR - TECHNICAL SEARCH 
SYSTEM SUPERVISOR - lOENTIFICATIONAERIFICATION 
SUPERVISOR - RESPONSE GENERATION 
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electronic transmission across the country^ In this case a 
reexamination of the Data Collection, Data Entry, And Response 
Generation Subsystems will arise because of the time required to 
transmit data. However, they could be accosmiodated within the 
existing set of functions. 

Consequently, the distinctions between interface types can be 
ignored since the basic six performance measurements listed above 
apply in every case and thus distinctions between interface types are 
not important. Also, it is clear that no more than these six 
performance requirements apply to interfaces given the definitions and 
assumptions listed above. 
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SECTION VII 


GENERAL REQUIREMENTS 


A. COMPUTER REQUIREMENTS 

The principal purposes of this section are: 

(1) To provide a system design approach to computer<-based 
subsystems . 

V C2) To establish functional requirements for computer-based 
subsystem design « 

(3) To establij^b general interface requirements for computers 
within system* 

1* Basic Requirements 

The following are the basic requirements for computer-based 
subsys terns: 

(1) Integrated control inputs and displays to allow operation 
of multiple devices from a single station console. 

0 . 

(2) All hardware, software, and documentation to be 

s ta nda rd i zed . fj. 

(3) Computer-to-computer communications to be standardized 
including areas of: 

(a) Hardware: Message switch controller. 

(b) Protocol: Communications procedures. o 

(4) Each processor to perform a single data system-related set 

9 ^. of control, data processing, and analysis functions. 

(5) Functions to be performed in a data-driven mode with no 
manual intervention, except for initialization, mode 
change, and reaction to alarms. 

(6) Appropriate computers to be equipped with mass storage 
used for: 

(a) Temporary data storage. 

0 

(b) Initialization values. 

(c) 


Program retention 


(7) Individual computers to be capable of recovering from 
power interruption by means of: 

(a) Own disk (where equipped)* 

(b) Subsystem ptocessor’s disk. 

(c) Nonvolatile, outage-protected memory (e*g*, 
read-only memory). 

(8) Redundant computers able to be switched to funct:ions for 
backup under System Supervisor control. 

(9) Redundant processors to be used for critical data paths. 

(10) Backup processors to be fully initialized and ready to j 

begin processing. 

■i 

(11) All processors to be capable of independent, stand-alone 
operation; no single failure to affect any other processor 
except for the interruption of data flow from the failed 
processor. 

(12) Appropriate subsystem processor to be equipped with a f 

printing device that can provide a permanent record of 

normal operations and diagnostics. 

(13) Each subsystem processor to be capable of providing J{ 

subsystem performance data, configuration data, and 

diagnostic messages to a display device at the central 

station console. „ 


2. Standardization 


a. Computer Glassifications . For the purposes of standardi- 
zation, computers may be divided into three classes. These classes 
are defined as: 


(l) Microcomputers: Very small computers intended for 

control of a single assembly of a portion of a 
subsystem with limited data processing capability. 



(2) Minicomputers: Small computers intended for 

subsystem control and capable of significant data 
processing. 

(3) Large computers: Sizable computers intended for 

extensive data processing including multi-processing. 


b. Standard Design . All processors within each of the thr<ie 
classes shourd"be a standard design, with standard peripherals. This 
permits: 
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(1) Interchangeability between asaembliee and peripherals. 

(2) Conmonality of software routines and subroutines. 

(3) Maintainability. 

(4) Minimum spares. 

(5) Minimum training when new processors are introduced. 


This requirement would be tempered to achieve the most reliable^ 
cost effective system design. 


All program initialization; operation; and documentation should 
be standardized to reduce operator training time and minimize 
operational errors. In particular; the Operator-computer interface 
should be standardized. For example,/ operator type-inS; computer 
mnemonics; and the protocol between the operator and the computer 
should be standardized. 


3. Modular Design 

All implementations involving the use of computers should be of a 
modular design with as much standardization as possible. Hie concept 
of modularizing and standardizing equipment is useful because it 
provides the maximum flexibility in equipment replacement and the 
smallest inventory of spares. 


4. Stand-Alone Capability 

All processors should have the capability of stand-alone 
operation. Such operation should include boot-strap loading (initial 
loading of a processor with a blank memory); program loading; and entry 
of operational parameters. The boot-strap loading of all processors in 
their stand-alone mode should be accomplished by the use of firmware 
(read-only memories which are non-volatile); a keyboard device; and/or 
a mass storage device. Program loading and entry of operational 
parameters should be accomplished by a keyboard device and/or a mass 
storage device. Portable; roll-around terminals may be used for 
maintenance and checkout. However; all devices needed to operate a 
processor in its stand-alone mode must be permanently attached. In 
addition; a printing device may be required to permanently record 
normal operations and diagnostics. 

'C\ 

When control is accomplished from the System Supervisor^ the 
message provided will indicate the program for the subsystem processor 
to select from its own mass storage device rather than sending the 
entire program through the comnunications lines. The operational 
parameters would be sent along with the message selecting the 
particular program to be used. All programs would have default values, 
which include the parameters most likely to be used. 
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SubsystAV Configuration and Mode Selection 

The aelection of the aubayatem configuration and <jiode ahouXd be 
pex'formed by the aubayatem proceaaor for that aubayatem. (Configur- 
ation here meana the interconnection of varioua aaaembliea in the data 
atream. ) 

I 

) ■ 

The mode of operation ia the particular operating method 
aaaociated with a particular data mode. 


6. Cloaed-Loop Control 

Functiona performed by aervomcchanioms requiring cloaed-10</i> 
control ahould be implemented ao that control remaina within the 
aubayatem. 


7. Safety Limita 

All computer-controlled functiona involving human or equipment 
aafety ahould be provided with functionally redundant backupa. The 
deaign ahould be auch that a failure of the computer can in no way 
cauae injury to personnel or damage to equipinent. 


0. Automatic Calibration 

All computerized aubayatema should have the capability to 
perform pre- and poat-work shift calibration of all assemblies in the 
subsystem. 

9. Fault Detection and Isolation, 

All computerized subsystems should include software with Che 
capability to perform self-tesCingi and automatic fault detection and 
isolation to the replaceable module level. This capability should 
exist both during prepaas calibration and during actual operations. 

All subsystems should be capable of self-testing of all internal 
controls and responses. 


10. Real-Time Diagnostics 

The subsystem processor should continuously monitpr all 
assemblies under its control, all its peripheral devices, and itself. 
An anomaly or failure should be logged 'and provided in an abbreviated 
form to the operators. 


V' 

1. . 
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®* General PiagnoBtic Maasage Reguirementa ^ Diagnostic 
roeaaagea for assemblies under the control of the subsystem processor 
should at least identify the source of the anomaly or failure and, to 
the extent possible, describe the nature of the problem* Diagnostic 
messages for the computer peripheral devices and for the processor 
itself should iraclude: 

(1) Memory address of the instruction last accessed 
before the problem occurred. 

(2) Contents of the program register at the time of 
anomaly. 

(3) Subroutine being executed at time of anomaly. 

(4) Process being executed when anomaly occurred. 

In addition'i if the nature of the problem warrants, the contents 
of all volatile registers in the computer should be listed. Wliere 
possible, a walk-back describing, the subroutine calls which led to the 
occurrence of the problem should also be provided. 


The diagnostic messages need not be in complete English text. 

The use of codes that can be identified and described more fully in an 
operating manual can be used to minimize the length of the actual 
diagnostic messages printed out. 


b. Specific Diagnostic Message Requirements . In addition to 
the general information listed in paragraph 10. a., a specific 
diagnostic message should include, but not be limited to, the 
following specifics: 


(1) Input/Output Device Error; The device and the 
nature of the problem should be included along with 
the process unde- execution when the error 
occurred. It should be stated whether the computer 
was reading or writing, and whether the error 
occurred in the peripheral device or internal to the 
processor. In addition, any attempt to read or 
write from devices not implemented with the 
particular processor should be identified. 

(2) Illegal Operation: Any illegal operation should be 

identified. 


(3) Guard Mode: VThen application software attempts tO 

access memory locations outside of its designated 
memory allocation, a guard mode message should be 
generated. 


(4) 


I 


f 

I: 




Arithmetic Error: Divide :^yerflow, floating point 

characteristic overflow, or iinderf low, and other 
arithmetic errors shouid produce diagnostic messages 
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11. Error Control 


Computer-to-computer connunications (within one facility) should 
provide reliable data transfer trith a probability of an undetected bit 
error occurring not to exceed one iii 10^. Detected errors should be 
logged automatically in a permanent form. 'Ihe processor detecting the 
error may either request retransmission of the data block in error 
from the transmitting processor nnd/or generate an alarm that data 
have been received in error. 


B. OPERATIONAL REQUIREMENTS 

1. Rapid Calibration and Turnaround 

Design should be such that pre-work shift calibrations may be 
accomplished for the entire operating system within TBS minutes and 
work shift calibrations with TBS minutes. Reconfiguration Without 
pre- or post-calibration shall be accomplished in TBS minutes. 


2. Reliability and Maintainability 

Reliability should be a principal goal and can be achieved 
through the use of both intrinsically reliable equipment and 
redundancy. Redundant computers should be used in all cases where 
communications are critical. 


C. STANDARDS 

1. Hardware 

Hardware standards should be in accordance with applicable 
Bureau and federal standards TBS. 


2. Software 

Software standards should be in accordance with applicab^'<^ 
Bureau and federal software development standards TBS. / 


3. Testing 

Each subsystem must be capable of being tested on a small scale 
before implementatinp on a large scale. Testing should be in 
accordance with applicable Bureau and federal standards TBS . 


4. Transfer to Operations 


Transfer to operations should be in accordance with Bureau 
standards TBS. 

“ .1 

Ji ■ 
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Documentation 


Training, operations, and maintenance manual should be in 
accordance with applicable Bureau and federal standards TBS . 


D. TECHNICAL SOPPORT 

' i' j 

There is a requirement that the systems, both hardware and 
software, be supported by technical people who can perform maintenance 
on the current systeot and plan and implement new systems as needed. 


E. FORECASTING AND RESPONDING TO ENVIRONMENT 

It is important to monitor the changing climate for identification 
services and to consider the impact of these changes on equipment, 
personnel,;! and facilities. 


1. Growth ^ 

From time to time special requests are initiated by the courts, 
the CongreWs, and other agencies such as the White House. These non- 
routine operations can vary from the clearance of special visitors to 
the White House to the requirement to expunge large numbers of records 
fron the criminal file due to redefinition made by the courts of the 
appropriateness of the file. The ability to accurately estimate the 
impact of all special requests is important since it allows for the 
orderly management of resources and the estimation of budget impact of 
each special request. 


2. New Requirements 

The ability to accurately estimate the impact of all new 
requests is important since it too allows for the orderly maiiagement 
of resources and the estimation of budget impact of each request. 
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APPENDIX 


ACRONYMS 


ACS 

APRS 

AHU 

/aids 

ANS 

ATS 

ATSPS 

AUTOCOR 

AUTORESP 

A&R 

BER 

BLO 

CCA 

CCH 

CCN 

CCNR 

CCR 

CIR 

CLASS-A 

CLASS-B 


Autoaated Classification Systen 

Automated Fingerprint Reader System f! 

Anti-Halation Underlayer 
Automated Identification Division System 
Automated Name Search 
Automated Technical Search 

i^tomvSted Technical Search Pilot System 

'*1 • 

Automated Correspondence Station (part of AIDS) 

Automated Response Generation (part of AIDS) 

Automation and Research Section of Identification Division 
Bit Error Rates 
Blocking Out 

Computerized Contributor Abbreviated Name 
Computerized Criminal History (part of NCIC) 

Computerized Criminal Name 

Computerized Criminal Name and Record (part of AIDS) 
Computerized Criminal (Arrest) Record (part of AIDS) 
Computerized Ident Response File (part of AIDS) 
Classification-A 
Class if ication-B 


CLASSIC Classification-C 

CLCK Classification Check 

CNR Computerized Non-Ident Response File 

COA 
CPU 




Age /' ■ 

''Central Processing Unit 
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CRS 

CRT 

CSORT 

DATE STP 

DBMS 

DEDS 

DENT 

DENT-A 

DENT-B 

.DOA 

DOB 

ECL 

EMI 

ENC 

ENCDOC 

ENCK 

ENDOCR 

ERR 

EYE 

FBI 

FEP 

FIFO 

FLAB 

FLOAD 

FP0 

FPCS 


f/P 


Conputerlsed Record Sent File (pert of AIDS) 

Cathode Ray Tube 
Centerline Sort 
Date Statap, Count and Log 
Data Base Management System 

Data Entry and Display Subsystem (part of AIDS III) 

Data Entry 

Data Entry-Cards 

Data Entry-Documents 

Date of Arrest (on f/p card) 

Date of Birth (on f/p card) 

Ehiitter Coupled Logic 
Electromagnetic Interference 
Encode Input Bata-Cards 
Encode Input Data-Documents 
Encode CheckrCards 
Encode Check-Documents 
Update Error File 
Color of Eyes (on f/p card) 

Federal Bureau of Investigation 

Front End Processor 

Pirst-In-First-Out 

Film Lab Process ing/Computer 

Film Load 

Fingerprint Classification 


Fingerprint Correspondence Section of the Identification 
Division 


Fingerprint 
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GDBMS 
GEO 

GPSS 

HAI 

HGT 

IBM 

ICI 

ICRQ 

ICS 

ICV 
ID, I.D. 
IDENT 
JPL 
KIPS 

LEAA 

MAIL 

MFim 

MIPS 

MMF 

MOE 

MTBF 

MTR 

MTTR 

NAM 

NASA 

NCIC 



General Purpose Data Base Management System 
Geographic Location (on £/p card) 

General Purpose Simulation System 
Color of Hair (on f/p card) 

Height (on f/p card) 

International Business Machines Corporation 
Image Comparison Identification 
Image Comparison Request 

I 

Image Comparison Subsystem (part of AIDS III, actually 
used for image retrieval for manual comparison) 

Image Comparison Verification 

Identification Division 

Identification 

Jet Propulsion Laboratory 

Thousands of Instructions per Second (as executed by a 
computer) 

Law Enforcement Assistance Agency 
Open Mail and Sort 

Image Capture Microfilm ‘ 

Millions of Instructions per Second (as executed by a 
computer) 

Minutiae Master File 
Measures of Effectiveness 
Mean Time Between Failures 
Master Transaction Record 
Mean Time to Repair 
Name (on f/p card) 

National Aeronautics ^and Space Administration 
National Crime Information Center 


NCR 

National Cash Regiater Company 


OCA 

Local Identification Number (on f/p card) 


OCR 

Optical Character Recognition 


ONB 

Office of Management and Budget 

V' 

ORI 

Originating Agency Identification Number (on f/p card) 


PCN 

Process Control Nuari>er 


PICS 

PCN and Image Capture Subsystem (part of AIDS III) 


PMT 

PhotoBRiltiplier Tubes 

■ ii 

POB 

Place of Birth (on f/p card) 

QC 

Quality Control 

I'i 

QUERY 

On-Line Query 

y 

li 

RAC 

Race (on f/p card) 


READ 

Quality Control Check, Read, Annotate 

■f 

ii 

RFI 

Radio Frequency Interference 


RH 

Relative Humidity 

f'j ■ 

If 

RVP 

Ridge Valley Filter 

i| 

SACS 

Semi-Automatic Classification System 

11 

SAR 

Semi-Automatic Fingerprint Reader 


SEAR 

Search Review 

' R 

SEX 

Reported Sex of a Subject (on f/p card) 

1 

SID 

State Identification Number 

i 

SKN 

Skin Tone (on f/p card) 

ii 

1 

1 

li 

h 

SOC 

Social Security Number (on f/p card) 

SPM 

Search Processor Module 

SS 

System Supervisor Subaystem (part of AIDS III) 

£. 

■ 

SSM 

Subject Search Module 

1 -5' 

SSRG 

Subject Search and Response Generation Subsystem (part of 

f 

n 

# 

h 


AIDS III) 

1 
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TDPA Top Down Functional Analysis 

TPC Technical File Conversion 

TR Transaction Record 

TRC Transaction Control File 

TSS Technical Search Subsysten (part of AIDS III) 

TTL Transistor - Transistor Logic 

VDENT-A Verify Data Entry-Cards 

VDENT-B Verify Data Entry-Documents 

VLSI Very Large Scale Integration 

Wand Out of System 


WAND 


